home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_1199 / 1193 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.7 KB
  1. From: mforget@elfhaven.ersys.edmonton.ab.ca (Michel Forget)
  2. Subject: Re: GEM List
  3. Date:     Sat, 30 Jul 1994 22:07:42 -0600
  4. Precedence: bulk
  5.  
  6. Hello Evan,
  7.  
  8. >vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
  9. >Oh, and there's another problem with app-defs... if you don't have a TSR
  10. >to load it (of course translate it into something useful) and put it in
  11. >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  12. >
  13. >Useful?  It is already in a useful form!  Why would you change it?  Let
  14. >the application writer use whatever form of lookup is best.  And what
  15. >makes you think you have to keep the whole file in memory?  The application
  16. >will load it, make whatever hash-tables or linked lists or whatever are
  17. >needed, and then free the ram!  Simple enough!
  18.  
  19. If a TSR is written, it would be nice if it could accept an evnt_multi()
  20. keycode/keyboard state (kr, ks) and return a structure of the following
  21. format:
  22.  
  23. typedef struct kc {
  24.      int scancode;
  25.      int ascii_code;
  26.      int left_shift;
  27.      int right_shift;
  28.      int control;
  29.      int alternate;
  30.      int capslock;
  31. } keycode;
  32.  
  33. That way when a program gets a keypress, it can ask the TSR to process
  34. it and then use the resulting value very easily.  I left the structure
  35. format very simple, but it could be improved.  I was thinking about
  36. using a bitfield for the last five values (save a lot of space that
  37. way) but what if Basic (or some language other than "C") has no support
  38. for bitfields?  Anyway, though, it would be worth having a TSR if it
  39. could do something like this for the program.
  40.  
  41. >What?  If the information is available, use it, otherwise, not.  A TSR?
  42. >Do you realize how many problems you'll have with that?  A reboot to change
  43. >a program option?   I think not.  And with memory protection, any time
  44. >you use a pointer to something outside your program, you are opening the
  45. >way to lots of problems.
  46.  
  47. True, but the problems could be worked out quite easily.  A little testing
  48. under memory protection is all that would really be required.  As for
  49. having to reboot, this is not exactly unheard of.  All GDOS changes
  50. require a reboot.  How do programs like ICFS get configured by CPX
  51. modules?  One (probably bad) idea would be to have the TSR check the
  52. size of the APP_DEFS.SYS file every time it is asked for a key
  53. structure.  If the size changed since the last time, reload the file
  54. and then respond to the request of the user.  That would have very little
  55. overhead (but maybe too much).  There are other ways, I'm sure.
  56.  
  57.  
  58. -- 
  59. Michel Forget           \\   mforget@elfhaven.ersys.edmonton.ab.ca    //
  60. Electric Storm Software  \\  ess@tibalt.supernet.ab.ca               //
  61. PGP Public Key Finger. = 1F C0 D3 FE 40 51 7F 47 F3 4A C6 AD 6E 02 71 85
  62.